What factors explain differences in learning climates?

Peer reviewe

Preliminary Design of JML: A Behavioral Interface Specification Language for Java

JML is a behavioral interface specification language tailored to Java(TM). Besides pre- and postconditions, it also allows assertions to be intermixed with Java code; these aid verification and debugging. JML is designed to be used by working software engineers; to do this it follows Eiffel in using Java expressions in assertions. JML combines this idea from Eiffel with the model-based approach to specifications, typified by VDM and Larch, which results in greater expressiveness. Other expressiveness advantages over Eiffel include quantifiers, specification-only variables, and frame conditions. This paper discusses the goals of JML, the overall approach, and describes the basic features of the language through examples. It is intended for readers who have some familiarity with both Java and behavioral specification using pre- and postconditions

Drillers' cognitive skills monitoring task.

Drilling incidents have emphasized that offshore drillers require a high level of cognitive skills, including situation awareness and decision making, to maintain safe and efficient well control. Although a number of tools for supporting operators' cognition are available in other high-risk industries, there is no specific tool for drilling. We developed a prototype monitoring task simulating drilling scenarios, Drillers' Situation Awareness Task, with drilling experts and piloted with 14 drilling personnel. Preliminary results suggest that it is viable as a tool for examining drillers' cognition and has the potential for training and formatively assessing cognitive skills in drilling

Modular subclass verification: safely creating correct subclasses without superclass code

The documentation of object-oriented frameworks and class libraries needs to provide enough information so programmers can reason about the correctness of subclass methods without superclass code. Even though a superclass method satisfies its specification and behaves properly in the context of the superclass itself, a new subclass may cause that method to have unexpected or unverifiable behavior. For example, inherited superclass code can call down to subclass methods which may cause a superclass method to no longer satisfy its specification. Furthermore, without superclass code, downcalls can result in unverifiable side-effects. Aliasing can also result in unexpected or unverifiable side-effects;In this dissertation, we present a reasoning technique that allows programmers, who have no access to superclass code, to avoid the problems caused by downcalls and aliasing. The rules use the specification of the abstract data representation of a class and the frame axiom of each method to determine when a method override is necessary and when verifiers can safely reason about the behavior of super-calls;We describe a type system and propose a tool that would warn when a super-call is unsafe or when a superclass method needs to be overridden. A verification logic is also presented and proved sound. The verification logic is based on specifications given in the Java Modeling Language (JML) and uses superclass and subclass specifications to modularly verify the correctness of subclass code;A set of guidelines is proposed for class library implementers that, if followed, guarantees that superclass methods will always be safe to call and that our verification logic can safely be used. These guidelines make our technique easy to use in practice.</p

Modular subclass verification: Safely creating correct subclasses without superclass code

The documentation of object-oriented frameworks and class libraries needs to provide enough information so programmers can reason about the correctness of subclass methods without superclass code. Even though a superclass method satisfies its specification and behaves properly in the context of the superclass itself, a new subclass may cause that method to have unexpected or unverifiable behavior. For example, inherited superclass code can call down to subclass methods which may cause a superclass method to no longer satisfy its specification. Furthermore, without superclass code, downcalls can result in unverifiable side-effects. Aliasing can also result in unexpected or unverifiable side-effects. In this dissertation, we present a reasoning technique that allows programmers, who have no access to superclass code, to avoid the problems caused by downcalls and aliasing. The rules use the specification of the abstract data representation of a class and the frame axiom of each method to determine when a method override is necessary and when verifiers can safely reason about the behavior of super-calls. We describe a type system and propose a tool that would warn when a super-call is unsafe or when a superclass method needs to be overridden. A verification logic is also presented and proved sound. The verification logic is based on specifications given in the Java Modeling Language (JML) and uses superclass and subclass specifications to modularly verify the correctness of subclass code. A set of guidelines is proposed for class library implementers that, if followed, guarantees that superclass methods will always be safe to call and that our verification logic can safely be used. These guidelines make our technique easy to use in practice.</p

Specification Facets for More Precise, Focused Documentation

Specification languages could aid reuse to a larger extent if they could document all important facets of software, not just functional behavior. Since a specification language designer cannot know exactly what aspects of a piece of software will be important, users should be able to do ``metaspecification''; that is, users should be able to declare new facets, and then use these facets to specify their software. Examples of facets that users might want to specify include time and space usage, safety considerations, aliasing, error checking, the user interface, etc.Copyright © Gary T. Leavens and Clyde Ruby, 1997.</p